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(54) Providing oivdemarKi access to network services for Networic Computers 

(57) Downloadable Virtual Environment Manager (VEM) 
middleware 108 enables applications executing on a 
network client such as a Network Computer 106 to access 
network services, includir)g system services such as 
pnnttng and local storage^ The VEM includes a Virtual 
Environment Supervisor (VES) 109 which configures the 
default client services to set up the user^ desktop, and has 
access to all sennces available on the n^work through a 
Service Directory Manager (SDM) 102 that maintains a 
Service Directory Table 114. An application executing on 
the Network Computer and wishing to use one of the 
services communicates with its local VEM. The VES checks 
the SDM to get the handle to the service (fig. 5) and, if the 
service has a stub, tfiis is downk>aded. The VEM then adds 
a service entry to Configured Services Table 110 that 
includes the service's handle and, if appropriate, a 
reference to the stub, so that the application can then use 
the service when required. 
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VIRTUAL ENVIRMMENT MANAGER FOR NETWORK COMPUTERS 



FIELD OF THE INVENTION 

•niis invention relates to network coiBputing. More specifically, this 
invention relates to methods and means for providing access to network 
services (for example, system services such as printing and local 
storage) to aK>lications executing on network connected computers. 

BACKGROUND ART 

As the network ceagniting paradigm becc»ies ubiquitous, simplified 
inexpensive desktop computers, known as the Network Computers, that have 
no means of independent existence will become common place. Such devices 
may run a low function operating system (for simplicity) and rely on 
servers for basic system services including local storage, printing, and 
monitoring. While traditional clients, such as PCs, provide their own 
basic system services they are also likely to seek additional services 
from the network. 

Existing approaches used to provide these basic system services to 
applications include the existence of a full-feature operating 
environment on the Network Computer and/or the requirement that each 
application provide its own set of needed services. The former approach 
is not feasible for network clients because these computers are not 
necessarily equipped with adequate physical resources such as physical 
memory and attached peripheral devices (e.g., disk drives) to support a 
full-feature operating environment (e.g., in the case of a Network 
Computer). The latter approach has the drawback of making each 
application aware of the platform and environment it can be run under so 
that it can provide support for necessary basic system services. 
Further, the former approach adds to the cost of the network clients, 
while the latter approach adds to the complexity in the design of 
applications. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a technique which 
alleviates the atxfVB drat^cks. 

According to the present invention we provide a method for providing 
access to network services to an application executing on a network 
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client, ccMnprising the steps of: determining when the application 
requires access to a remote network service; in response to a 
determination that the application requires access to the remote network 
service: locating the remote network service required by the application 
on demand; and downloading at least one object into a memory of the 
network node that enables the application to access the remote network 
service on demzmd. 
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Further according to the present invention we provide a method for 
providing on-demand access to system services to applications executing 
on a network computer, comprising the steps of: a) in response to a 
demand from a user, downloading a virtual environment manager that 
provides access to remote network services; b) identifying a set of 
system services; c) configuring the set of system services by contacting 
15 appropriate remote service providers and downloading the client stubs or 

a handle for each service; d) maintaining a list of configured services; 
and, e) providing access to the configured services. 
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In a preferred embodiment a downloadable middleware called the Virtual 
Environment Manager (VEM) is provided. The VEM allows applications to 
be developed coxcpletely independently of the architecture and environment 
of a client computer and the servers it connects to. For a client (i.e., 
a network coraputer) to access a service, the VEM queries a Service 
Directory Table available on one or more connected servers- The access 
to the Service Directory Table returns a handle, which is used to connect 
to the indicated service provider. 



In a preferred embodiment, a method for providing access to network 
services to an application executing on a network client is proposed. 
The method coitqprises the steps of determining that the application 
requires access to a remote network service. In response to this 
determination, the remote network service required by the application on 
danand is located, and at least one object is downloaded into a memory 
of the network node that enables the application to access the remote 
^5 network service on demand. 

Preferably, the network client is a Network CcMcputer, the network node 
is a JAVA terminal or a personal digital assistant and the network 
service is a System Service. 
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in different alternate embodin^nts . the system service »ay be a printing 
service or persistent storage. 

in other embodiments, the system service is system monitoring or system 

management . 

BRIEF DESCRIPTION OF THE DRAWING 

The present invention will be understood hy reference to the drawing 
v^erein : 

Figure 1 depicts a loosely coupled system suitable for use with the 

present invention; 



Figure 2 show the flow chart for the boot phase of the 



network computer; 



Figure 3 shows the flow chart for initial steps taken by each service 
provider; 

Figure 4 shows an instance of the system state with the VEM configured; 

Figure 5 shows the flow control process for an application when it wishes 
to use a network service; and. 

Figure 6 shows an exaaqple desktop. 

DETAILED DESCRIPTION OP THE PREFERRED EMBODIMENT 

A loosely coupled system suitable for use with the present invention is 
Illustrated in FIG. 1. The system includes several computers 102-106 
interconnected by way of a communication network 112. of these 
computers, some are known as Network Computers 106(1). 106(2). because 
they rely on services available via the network to provide many of their 
basxc functions. Others are known as service providers 104(1), 104(2) 
104(3) because they provide network services, such as basic system 
services, to the Network Cc««,uters. Some of the computers are also known 
as service Directory Managers (SDMs) 102. because they maintain a list 
of services that are provided to network computers by the service 
providers . 



lUe Network Computers 106 can be embodied, for example, on a JAVA 
terminal, a personal digital assistant (PDA) or an internet terminal. 



The communication protocol is HTTP and TCP/IP. The network 112 can be, 
for exainple, a token ring. The service systems 102, 104(1), 104(2), 
104(3) can be embodied, for example, on IBM RISC Sy3tem/6000 machines 
using AIX 4.2. 

A logical orgemization can be placed on the physical system described 
above* This organization can be described by a three tier client /server 
strategy. In this strategy, tier 1 represents the client function, tier 
2 represents the service provider and tier 3 represents the data object 
server (i.e., information storage). The system described in the present 
embodiment relates to tiers 1 and 2 and the interface in between. The 
interface in between tiers 2 and 3 is unrestricted, so users can rely on 
conventional, tried and true data information access systems. Note that 
a service provider can be designed to either reside completely on a tier 
2 server or to allocate its function between tiers 1 and 2 by providing 
a special service stub. 

Each Network CcHoputer includes a Virtual Environment Manager (VEM) 
108(1), 108(2) that is downloaded frcan a Service Provider by way of the 
conmainication network 112 . The VEM is embodied as program code 
instantiated in the random access memory (not shown) of the Network 
Cc^nputer. In particular, the VEM provides a base class called VEMCLASS 
(defined in Appendix A) that it relies on for defining a collection of 
objects (in the sense of "object oriented programming"). One of the 
objects included in each VEM is an active entity called the Virtual 
Environment Supervisor (VES) 109(1), 109(2) that is responsible for 
maintaining the VEM state. In a preferred embodiment, the VES is an 
active JAVA object and is directly instantiated from the VEMCLASS. The 
V^ state includes a table of configured services 110(1), 110(2) and a 
table of active applications 112(2), 112(2). Both the table of 
configured services and the table of active applications are also 
instantiated in the random access merory of each Network Computer. 
;^plications inherit from the VEMCLASS in order to interact with the VES. 
The object class is compiled with the application and bound to the name 
space of the application. 

According to an embodiment of the present invention, when a network 
computer is switched on, it goes through a boot process in which it 
readies itself for use. At the end of the boot process, the network 
computer prompts the user for identification. The identification process 
can be, for exsmiple, typing in the user name and a password. After user 



identity verification, the network computer presents the user with a 
desktop environment. 

The desktop environment is preferably a JAVA container. The JAVA 
container runs on top of a JAVA virtual n^chine. Both the container and 
the JAVA virtual machine are provided by a program such as a Web Browser 
114(1). 114(2) (e.g. Netscape Navigator) which executes on the Network 
computer, o^e browser can be downloaded during the Network Computer's 
boot sequence or provided as an integral part of the Network Computer. 

AS part of the initialization process, the browser downloads the VES and 
a configuration file for the user from a Service Provider. The VES uses 
the configuration file to set up the user's desktop environment 
(desktop) . An example desktop (which can be in the form of a home page) 
as shown in Figure 6. The configuration file contains a list of system 
and application services that the user accesses most frequently. These 
system and application services can be embodied as icons 602 or buttons 
604 and/or a textual list 606 displayed on the desktop. The system and 
application services can be accessed as hyperlinks or as direct control 
buttons Where the appropriate JAVA code has been downloaded. The 
remainder of the VEM is downloaded with user applications. 

The initial logging and download of the home page is described in FIG 
2. in step 202 the Network Computer is powered on or reset by a user 
In response, in step 204 the Network Computer commences its machine 
specific, conventional boot sequence. This sequence can be extended to 
xnclude downloading of the Web browser. m step 206. the Network 
computer prompts the user for a usemame and password. The Network 
Computer uses conventional methods to determine if the usemame and 
password are valid in step 208. Those of skill in the art will recognize 
that steps 206 and 208 could alternatively be performed as part of step 
204. If step 208 determines that either the usemame or password are not 
valid, the method retums to step 206. If the usemame and password are 
valid, m step 210 the Network Computer downloads the VES and the 
configuration file. 

When a VES is downloaded for a user, it initiates configuration of all 
services that are in the configuration file. The configuration file can 
be Of a conventional flat file format. For example, the configuration 
fxle can be in the form of a Bookmarks file of the type used by Netscape 
navigator 3.0. •n.is configuration is performed by contacting the 



appropriate service providers and initializing the client's tcible of 
services 110 with the server information. Stubs are also downloaded for 
those services that reside on both tiers 1 and 2. 

In addition to the currently configured services, the VES has access to 
all services available on the network. This enables a user to add any 
available service to the desktop and as a result to the user's 
configuration file. 

Service access is provided by a Service Directory Memager (SDM) that 
maintains a teOt>le of services referred to as the Service Directory TeOsle 
(SOT) 114 (shown in Figure 1) . The Service Directory Tca>le contains 
information about system and application services offered by the Service 
Providers on the network. It should be understood that there can be a 
plurality of SEMs on the network, each maintaining a SDT or accessing a 
single instance of the SDT. 

When a Service Provider is connected to the network, it announces the set 
of services it offers to the SDM. The steps taken by each Service 
Provider in announcing the set of services it offers are shown in Figure 
3. In step 302 the Service Provider generates a list of services that 
it offers. In step 304, the Service Provider identifies the SEM that is 
responsible for maintaining the list of services in the network. In step 
306 the Service Provider scans the list of services and determines the 
next service to be registered. If there is another service to be 
registered, in step 308 the Service Provider sends a REGISTER message to 
the SDM (directory M) and then returns to step 306. If there are no more 
services in the list, initialization is ccanpleted in step 310. It should 
be iinderstood that steps 306 and 308 can be replaced with a single step 
in which the entire list is read only once emd then sent to the 
appropriate SDM as part of a single message or message sequence. 

An instance of the system state in which various client stubs are located 
at the Network Ccanputers is shown in Figure 4. The Figure shows three 
Service Providers: a Print Server 402, a Fax Server 404 and a Mail 
Server 406. The SDT 408 includes information cax>ut the three service 
providers. In particular, the information describes the type (attribute) 
of service and the location of the Service Provider which provides the 
particular service. The particular instance of the Network Computer 410 
includes various applications 412 (APl-APn) , an active VES object 414 
v^ich contains a table of configured services and passive stub objects 
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416 (Print Client Stub. Pax Client Stub, Mail Client Stub) that provide 
connections to the services. The VEM includes the VES. the stubs and the 
VSfCIiASS portion of each application. 

The VEM will now be discussed in more detail. For reference, code 
definitions for the VEM include the VEMCLASS and the client and server 
interfaces. These are is shown in appendices A and B respectively. 
Figure 5 shows the flow control process for an application when it wishes 
to use a network service. As previously discussed, loading the VES into 
a client is analogous to looking at an HTML page in a browser. The VES 
is downloaded and it's initO method is called. The init() method 
synchronizes itself to ensure that the class variable VE_supervisor is 
initialized only once. Any subsequent attempts to start a VES are 
disabled. The VES assigns itself id=0 by setting the VEM_id instance 
15 variable. The class variable, nunuAFE. is then incremented. A registry 

(that contains the Configured Services Table 110 and the Table of 
^plications 112) and a shared_services table are created. Finally, a 
directory services remote object is instantiated, using the DS_server 
parameters passed in the html file. 

20 

Once the VEM has been downloaded and initialized, applications (APs) can 
be downloaded. (Note that APs are ,assumed to be aj^lets in this 
discussion. The VEM supports applications, though applets are preferred 
for improved manageability.) In it's init{) method, an AP should call 
25 the registerAFEO method. This call sets the AP's instance variable. 

VEM_id. to the class variable num_J^. and incranents num_AFE. Since 
nuin_AFE is never decremented, the AP now has a unique id. The VES is 
then called to create an entry for the AP in the registry (the Table of 
Applications 112). At this time, the entry contains only the applet 
object reference, id and name, but it can be expanded later as needed. 
The registerAFEO method returns a unique key, called a -cookie", to the 
AP to ensure that access to the AP information in the registry is 
controlled. The AP is now fully integrated into the VEM environment and 
is now capable of VEM function. 
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When the AP needs a service, it first requests the VEM to register the 
service using one of the registerService ( ) methods. On service 
registration the VES checks the directory service (the SDM) using the 
LookupServiceO method to get the handle to the service and to see if the 
service has a stub. If it does, the stub is downloaded. The VEM then 
adds a service entry to the registry (the Configured Services Table 112) 
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that includes the service's handle and, if appropriate, a reference to 
the stub. A cookie is passed back to the AP. Once the servic4 is in the 
registry, both the AP and the VES can access it as needed. 

The choice of v^ich registerService( ) method is called depends on: (1) 
whether a generic service is needed (i.e. one identifiable with just a 
name), or v^ether a more custom service is needed (e.g. one that is 
identified with a list of attributes as well as a name); and (2) whether 
the service shared. If the service is not shared, then the AP 
registering the service is the only one that gets access to the cookie. 
Otherwise, if the service is present, a cookie is passed back that is the 
same as those given to other APs for the service. If a shared service 
is not yet available in the VBl, the shared^service variable is updated 
to reflect the availability of a new, shared service, and a new cookie 
15 is passed back to the AP. 

Access to shared services can be controlled using an access control list. 
Alternatively, shared services can be globally available, i.e. any AP can 
receive the cookie for the service just by asking for the service. 
Shared services are useful for minimizing the number of server stubs 
resident on a client. They can also be useful if service behaviour 
changes caused by one AP are used by another interactively. 
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Shared services can be removed from the VEM in various ways. According 
to a first embodiment, a reference count is kept for each service. The 
reference indicates how many APs currently have access to the service. 
When the reference count reaches zero, the service is removed by the VES. 
According to an alternative embodiment, only the AP that originally 
brought in the service is allowed to remove it. 



Once the Vm state has been updated to include the service, the AP can 
get the handle by issuing the getServiceHandle ( ) method, or get the stub 
by using the getService Instance ( ) method. The AP is then free to make 
a connection of any sort and use the service. T^ie VEM can be embodied 
35 to restrict how an AP and service communicate. When the service is no 

longer needed, the AP calls the RevokeService () method that updates the 
VEM state as follows: if the service is unique to the AP then the 
service is removed; if the service is a shared service then it is 
r^noved in accordance with the rules discussed above. 

40 



APPENDIX A 

I* 

* ™ ^ INSTANrnXES AlW THAT THE 

*^ APPUCATIONS INHERIT IS SHOWN BELOW. 

P^'f*'^ ^^°^SS extends Applet implements VEMBaselnterfacc { 

The VEjupervisor is a single variable available to the VES and to aU applications 

private static VEMCLASS VE_supervisor = nuU- 
mlS^fms-l '^'^'^"'''^y ^^'^ for generating 

private static int num_AFE = 0; 
^ /* VEMJd is a variable per application thai provides storage of an application's ID 

protected int VEMJd; 
private Hashtable legistiy; 

I* The sharedjervices variable provides a quick search mechanism for 

shared services */ 
private Hashtable shared_seivices; 
^/* The String primary, secondary DS_server variables store the location of the SDM 

private String primaiy_DS_servcr, secondary_DS_server; 
f*pie directory variable provides dUrect access to the SDM */ 
private ServDir directory; 

pubUc VEMCLASSO{ 
) 

public void initQ { 
} 

/* 

V^nST*^"^™^ ™^ VEMBaselnterface DESCRIBED IN 

*/ 

public Cookie registwAFECString name) 
^ throws VEMRegistryException { 

pubUc Cbokie registerServicc(String name) 
^ throws VEMRcgistiyException { 

public Cbokie «^isterService(String name,Stringn attrs) 
^ throws VEMRegistryException { 



10 



public Cookie registerService(String name, boolean shared) 
throws VENfRegistryExcq>tion { 

} 

public Cookie registerService(String name,StringD attrs, boolean shared) 
throws VEMRegistryException { 

} 

public ServiceHandle getSaviceHandle(Cookk c) 
throws VEMRegistryExcq)tion { 

} 

public Object getSeTviceInstance(Cookie c) 
throws VEMRegistryException { 

} 

public boolean revokeService(Cookie c) 
throws VEMRegistryException { 

} 

I* 

* INTERNAL ROUTINES TO DIRECTLY MANAGE THE VES STATE 
*/ 

synchronized private void addToRegistry(Cookie c, RegistryElement r) 
throws VEMRegistryExcq}tion { 

} 

synchronized private R^istrymement getFromRegistry(Cookie c) { 
} 

synchronized private String removeFroniRegistry(Cookie c) 
throws VEMRe^stryException{ 

} 

synchronized private Cookie shareService(int o. String name) { 
} 

synchronized private void removeIfShared(int o. String name) { 

} 

} 
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APPENDIX B 

/* THE VEM BASE INTERFACE */ 

public inter£ace VEMBaselnterface { 
public static final boolean SHARED = tiue; 

/* 

I Methods to notify VEMSiq)eivi5or of resident application fi-ont ends. A I 
I unique key is passed back to allow only the appUcation and VEMSupervisor I 
I access to any VEM state infonnation of die application. I 



/* 

I Register the Application ftont End (AFE) widi the VEM 
*/ 

public Cookie iegisterAFE(Stiing name) 
dirows VEMRegistryExcq)tion ; 

/* 

I Methods to notify VEMSuporvisor of required sovices needed by an AFE. I 
I This call updated VEM state with a handle to a service that the AFE can I 
I dynamically access. The AFE sets up communication witii the service I 
I using the handle. A unique key is passed back, allowing the AFE I 
I exclusive access to die service handle. I 
. . 

/* 

I Set up the VEM state with a handle for any service with the name "name". 
*/ 

public Cookie registerService(String name) 
throws VEMRegistryExcq)tion ; 

/* 

I Set up die VEM state wifli a handle for a service widi die name "name", 

I and containing die attributes "attrs", 

*/ 

public Cookie registerService(String name^tring[] attrs) 
dirows VEMRegistryException ; 
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I* 

I If shared is equal to "SHARED", Lc, true, then see if service with the 
I name "name" is known to the VEM. ff it is not, set up the VEM state 
I with the Glared service and set die owner to "this" AFE. Return die 
I associated key. 
*/ 

public Cookie iegisterService(Stiing name, boolean shared) 
throws VEMRegistryExcq)tion ; 

I* 

I If shared is equal to "SHARED", i.e., true, then see if service with the 
I name "name", and attributes "attrs" is known to the VEM. If it is not, 
I set up die VEM state widi die shared service and set die owner to "diis" 
I AFE. Return the associated key. 
*/ 

puWic Cookie registerService(String name,String[] attrs, boolean shared) 
dirows VEMRegistryExcq>tion ; 

I Mediods for AFE to get access to semces known to VEM 
»/ 

y* 

I Get die handle associated with a service that can be used to set up 

I a connection with die service 

*/ 

public ServiceHandle getService(Cookie c) 
tfirows VEMRegislryExcq[>tion; 

/* 

I Get access to a service stub, oftwi used for shared sovices. 
*/ 

public Object getSeiviceStub(Cookie c) 
dirows VEMRegisliyExcq>tion; 

I* . 

I Method to remove a service from all VEM state. | 
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/* 

I Remove the service identified witfi the key. If the service is shared, 

I only tbc owner AFE is allowed to remove it 

*/ 

public boolean ievokeService(Cookie c) 
^ duows VEMRe^tryException ; 

/* THE SDM lOTERFACE */ 

pubUc interface VEM_ServDir extends javajmi.Remote { 



I Mediods to lookup services. A handle is returned for a service even if I 
I It IS marked "faUed". TTie cKent decdies what to do with it The returned I 
handle looks like {<ip_addrcss>:<port #>:<flag>}. The flag may be "foiled" I 
I or "aHve". I 



/* 

^Return service handle for die first service diat matches service name 

String lookUpService (String ServiceName) 
dmws javajmi.RenioteException; 

/* 

I Return service handle for die first service that matches service name and 

I all attributes 

*/ 

String lookUpService (String ServiceName. StringQ ServiceAtir) 
daows javajrini.RemoteException; 

/* 

I Return service handle for the "next" service diat matches service name and 
^that comes "after" die supplied service handle 

String lookUpService (String ServiceName, String ServiceHandle) 
throws javajmLRemoteException; 
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/* 

I Return sendee handle for the "newsservice that mashes service name and 

I all attributes and that comes "afto"" the supplied service handle 

*/ 

String lookUpService (String ServiceName, String ServiceHandle, 
Stringn ServiceAttr) 
throws javajmi.RemoteException; 

/* 

I Methods to get service counts. Counted also if mariced "failed". I 



/* 

I Return count for matching service names 
*/ 

int getServiceCount (String ServiceName) 

throws java^rmLRemoteException; 

/♦ 

I Return count for matching service names and attributes 
*/ 

int getServiceCount (String ServiceName, StringQ SoTvdceAttr) 
throws javarmi JlonoteException; 

/* 

I Mediods that return meta information about services. Meta infomiation I 
I includes "failed" as well as "alive" services I 



/* 

I Retum an array of strings. The first element is the name of the service, 

I die rest are attributes. Input is service handle* 

*/ 

StringQ getSaviccNameAttr (string SeiviceHandle) 
throws javajmi JlCTiotdException; 
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I* 

I Return an array of strings. Each element of that array contains attributes 
I of the service separated by special delimiter "$". We stipulate that 
l^service names, attributes, and service handles not contain "S". 

stringO getSciviceAttr (string ServiceName) 
throws javajmLRanoteExcq>tion; 

/* 

I Return an array of strings. Each element of diat array contains first 
I the service name, followed by service attributes. All are delimited by 
I the "$" character. 
*/ 

stringQ getUstOfServices 0 

throws javajmi.RemoteException; 
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dJlIllS 

1. A method for providing access to network services to an 
application executing on a network client, con5)rising the steps of: 

determining when the application requires access to a remote 
network service; 

in response to a determination that the application requires 
access to the remote network service: locating the remote network 
service required by the application on demand; and downloading at 
least one object into a memory of the network node that enables the 
application to access the remote network service on demand. 

2. The method of Claim 1 wherein the downloading comprises the step 
of contacting an appropriate service provider and downloading a client 
stubs for the remote network service. 

3. The method of Claim 1 wherein the downloading conprises the step 
of contacting an appropriate service provider and downloading a client 
handle for the remote network service. 

4. The method of any preceding Claim comprising the further step of 
providing a user of the network client with a visual display of 
available network services to vrtiich access has been previously 
enabled. 

5. The method of any preceding Claim wherein a virtual environment 
manager running on a virtual machine instantiated on the network node, 
provides access to the network services. 

6. The method of any preceding Claim coirprising the further step of 
determining when access to the network service is no longer needed; 
and, initiating a removal of the object from the memory of the network 
node. 



7. The method of any preceding Claim cwnprising the further steps 
of registering by remote service providers with a third party 
directory, a set of services available to network clients, wherein the 
object obtains access to the service reference to the directory. 
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8. The method of any preceding Claim comprising the further step of 
sharing access to the service by a plurality of application executing 
on the network node. 

5 9. The method of any preceding Claim coii5)rising the further step of 

isolating the service needed by an application from other applications 
by providing access to the service only by way of a unique key known 
only to the application. 

10. A method for providing on-demand access to system services to 
applications executing on a network ccmputer, ccai^rising the steps of: 

a) in response to a demand frcMn a user, downloading a virtual 
environment manager that provides access to remote network services ; 

b) identifying a set of system services ; 
configuring the set of system services by contacting 

appropriate remote service providers and downloading the client stubs 
or a handle for each service; 

d) maintaining a list of configured services; and, 

e) providing access to the configured services. 
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11. l!h& method of Claim 10 comprising the further step of sharing 
access to the system services by a plurality of the applications. 
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